home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2748 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.5 KB
  1. Path: Hermes.grace.irl.cri.nz!maths!peterm
  2. From: peterm@maths.grace.cri.nz (Peter McGavin)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS frien
  5. Date: 05 Feb 1996 01:31:39 GMT
  6. Organization: Industrial Research Ltd
  7. Distribution: inet
  8. Message-ID: <PETERM.96Feb5143139@tui.maths.irl.cri.nz>
  9. References: <4e8h9j$mp5@sinsen.sn.no>
  10.     <4e8pk2$ntm@serpens.rhein.de><3873.6603T379T952@wr.com.au>
  11.     <PETERM.96Jan31172831@tui.maths.irl.cri.nz>
  12.     <3274.6607T382T680@wr.com.au>
  13. NNTP-Posting-Host: tui.grace.cri.nz
  14. In-reply-to: accolyte@wr.com.au's message of 3 Feb 1996 10:04:51 GMT
  15.  
  16. accolyte@wr.com.au (Accolyte) writes:
  17. >> Do you know how to handle interrupts from my GVP Spectrum card?  From
  18. >> my WarpSCSI?  From my network card?  From my brother's OpalVision or
  19. >> Z3FastLane?  From MPEG cards?  From hardware that hasn't been designed
  20. >> yet (like new Amigas)?  Disabling any of those interrupts for too long
  21. >> can cause all sorts of nasty things to happen, like lockups, network
  22. >> failures, corrupt displays and/or corrupt hard disks.
  23. >
  24. >Ah so that's what he was getting at. Like it or not this is rare though.
  25.  
  26. Well it happens to people all the time.  And the hardware is not to
  27. blame.
  28.  
  29. >For compatibility one might consider using the system interrupt routines
  30. >as an *option* to the user, but taking over the interrupts should always
  31. >be available for those who want speed.
  32.  
  33. Unless we're getting thousands of interrupts per second (which
  34. indicates we're probably using the wrong algorithm), no-one will
  35. notice the difference.  Oops, yes they will --- it makes the
  36. difference between work/crash on some configs.
  37.  
  38. >I'm just the opposite, I tend to forget about system ones. ;)  If a 
  39. >hardware bashing game doesn't run, it's the coder's fault not the fault
  40. >of the concept of hardware bashing in general. I've already mentioned
  41. >a few of the above in another post, but:
  42.  
  43. I agree it's the coder's fault.  The OS allows hardware bashing after
  44. checking-for and allocating the hardware.  Of course this is at the
  45. expense of compatibility with other hardware.
  46.  
  47. >Diamond Caves:  Too slow, and plays nowhere near as well as BaldersGrove
  48.  
  49. Could it be the high-res interlace mode that slows Diamond Caves down?
  50. In any case, direct bitmap access is possible without killing the OS
  51. and Diamond Caves probably doesn't have an option for that.  I wonder
  52. whether BaldersGrove works at all on my system.
  53.  
  54. >Gloom Deluxe:   Point. Although it requires a much faster system to run
  55. >                acceptably. The stock 1200 routines are not system ones.
  56.  
  57. Gloom Deluxe would be faster on an A1200 if it didn't kill the OS and
  58. if it used QBlit() for c2p.
  59.  
  60. >Spectrum Emul:  Not a game :)
  61.  
  62. So what if it's not a game.  It's 10000 games, many of which are
  63. better than ones in this list (arguably).
  64.  
  65. >Colonization:   Shocking code, and this in terribly slow, even for OS calls.
  66.  
  67. So how does killing the OS improve shocking code?
  68.  
  69. >DuneII:         Could be much faster
  70. >Angband:        If it's what I'm thinking of (moria clone?) then that's
  71. >                on par with the ol' text adventures in terms of system
  72. >                requirements :)
  73.  
  74. And people write text adventures and disk mags that kill the OS  :-(
  75.  
  76. >F18Interceptor: I can't remember this, but I'm sure it could've been much
  77. >                faster/better.
  78.  
  79. F18 Interceptor was written when A500s were the norm and it's still a
  80. classic, fast flight simulator.  I can run my network server in the
  81. background and I can't tell when someone accesses my hard disk unless
  82. I look at the disk light.
  83.  
  84. >Poing:          I admit, this is a downright trendy/addictive game :)
  85. >                But it's not overly complex is it?
  86.  
  87. It would have to be incredibly complex before I would consider killing
  88. the OS.  Far too many coders decide to kill the OS from the start.
  89.  
  90. IMHO all the above games are better than you make out.  On the other
  91. hand, none of them are perfect.  Some use only high-level OS calls,
  92. hence they work with gfx-cards but are relatively slow on stock
  93. A1200s.  This problem can be worked around without killing the OS.
  94. Indeed, all the games above could almost certainly all be improved
  95. without killing the OS.
  96.  
  97. >I think the trend is that the ONLY OS programmed games that will run
  98. >acceptably are the simple ones, and the ones designed for graphics
  99. >cards only. Where does that leave the people who don't have/want a 
  100. >graphics card?
  101.  
  102. To work with all gfx cards, a game must use high-level OS calls.  If
  103. that's too slow on a particular chipset then the game can allocate and
  104. bang within OS rules.  A good game would give the user both options.
  105. -- 
  106. Peter McGavin.   (p.mcgavin@irl.cri.nz)
  107.